\section{Information-Centric Networks(ICN) Architecture}
\label{chap:informationcentricnetworks}
In this section, we focus on ICN Architecture, where we also describe briefly some of the proposed approaches for implementing it, but we go in details with Content-Centric Networking (CCN) approach with specific information of its components and the way the content data precede, as an example for illustrating the idea of ICN. \bigskip

\noindent Most of nowadays communications go through the Internet where different data in a huge quantity is transported between computers all over the world. Information has also become at the heart of all Internet communication, therefore a new technology that can interconnect information and data is needed.\bigskip

\noindent Information-Centric  Networking is a new approach with a different foundation compared to the current Internet architecture, which focuses on end-to-end communication between hosts. The architecture of ICN focuses on the on information objects and receiver interest in the network and distributes these objects all over the Internet in an efficient and reliable way.\bigskip

\noindent Information-Centric Networking aims to use names to address objects (content), where security is directly applied to it, and to forward content on a developed network infrastructure that enables efficient and secure content distribution with high availability regardless of its location. The Internet user would want service access and data retrieval and is oblivious to its location \cite[p. 13]{BRITO}.\bigskip

\noindent Named content, security directly applied to contents and in-network cashing are some of the concepts that \textit{``allow ICNs to deploy a more efficient architecture for content distribution, thus avoiding all the `patches' needed by the current Internet architecture such as IP Multicast, DNS and IPSec''} \citep[p. xi]{BRITO}\bigskip

\noindent The Internet has also grown to be a huge commercial success, why many approaches towards ICN have been invented and introduced to set more focus on future evolved Internet.

\subsection{Naming}
In the current Internet architecture, to retrieve data, we have to know the IP address. ICN approaches are quite different with the host-centric approach. ICN put more emphasis on content's name rather than its location and identification in traditional approach.\bigskip

\noindent A perfect ICN architecture should fulfil specific characteristics on naming to achieve the goal of ICN. First, ICN names should be unique. This is to assure the uniqueness of the content identification. Secondly, ICN names must be persistent. This is to make sure the validation of content name can synchronize with the validation of the content. Thirdly, ICN names have to be scalable. No matter what kind of the namespaces are, ICD names can serve them without any limitations, like small or large namespaces \citep[p. 14]{BRITO}. \bigskip

\noindent There are mainly three naming schemes in ICN: flat naming, hierarchical naming, and attribute-based naming \citep[p. 14]{BRITO}. \bigskip

\noindent Flat naming are \textit{``randomly looking sets of bits used to identify objects''} \citep[p. 14]{BRITO}. Flat naming scheme use a cryptographic hash function, which assures the content identification's uniqueness. Flat naming is persistent, as \textit{``there are no explicit rules to bind information into the content identifier format or meaning''} \citep[p. 14]{BRITO}. There are some problems existing in flat naming scheme. One is that the identification is not user-friendly, as cryptographic hash function being used, which hides the underlying content's semantics and also makes the names difficult to remember. \citep[p. 50]{BARI} Another one is that flat names cannot be aggregated into prefixes. Sequensely, an explosion may happen in the size of the forwarding and routing table \citep{SOLIS} \citep[pp. 14-15]{BRITO}.

\begin{figure}[h]
\begin{center}
\includegraphics[scale=1]{./Pictures/Figure6.png}
\end{center}
\caption{An example of hierarchical name \citep[p. 16]{BRITO}}
\label{fig:6}
\end{figure}

\noindent Hierarchical naming scheme uses different string name components. It structures very much like a Uniform Resources Identifiers (URI), as we can see an example below. Therefore, many mechanisms already been proposed, which can deal with IP address, can also deal with Hierarchical names. This kind of naming scheme is very user-friendly and a human-readable. Somehow, this scheme could not support persistence. Changes on content also should be changed in the names components. However, this can't be guaranteed. For example, non-persistence might happen, due to the content ownership changes \citep[pp. 16-17]{BRITO}. \bigskip

\noindent Attribute-based naming scheme is quite different with other. This scheme \textit{``does not provide a unique identification for each and every content''} \citep[p. 17]{BRITO}. This scheme uses a form: [attribute = value], which is called attribute-value pairs (AVP). A set of constraints is used together with the form, which enables aggregation. By using attribute-based scheme, there is no need for end users to use external applications or mechanisms. Therefore, verifying what content meet end users needs is their own responsibilities in this scheme.  End-users may have to face with a situation that deals with too much or too less information \citep[p. 18]{BRITO}.

\subsection{Routing}
ICNs request content by its name, not its location. This leads the ICN routing has to fulfil some characteristics. Firstly, the ICNs routing has to be content oriented. Packet has to be addressed to the content names, not the location. Secondly, ICNs routing has to robustness and strong functionalities on fault tolerant and rapidly redistribution, in case faults are delivered to users. Thirdly, routing in ICNs has to be efficiency and not cause high network traffic. Fourthly, ICNs routing has to be flexible and scalable to serve both complicated and simple local network \citep[p. 18]{BRITO}. \bigskip

\noindent In general, ICN has two types of routing. They are hierarchical routing and no-hierarchical routing.\bigskip

\noindent Non-hierarchical routing, which is also called un-structured routing, doesn't have dedicated structures for storing routing information and doesn't organize routers in hierarchical structures. That means that non-hierarchical routing will allow all nodes to obtain valid content by linking each node. Nodes in ICN have to calculate the best routes to deliver the content to the. This type of routing will allow multiple paths to deliver the same content, \textit{``once the knowledge of the entire network topology allows the calculation of loop-free routes and increases the availability of the network as a whole, because there is no single point of failure''} \citep[p. 18]{BRITO}. \bigskip

\noindent Hierarchical routing is also called structured routing. The routers in hierarchical routing are organized into several hierarchical levels, \textit{``hierarchical routing protocols are able to reduce the amount of control information, exploiting the hierarchical relationships between these routers''} \citep[pp. 19-21]{BRITO}.\bigskip

\noindent There is another rooting scheme called name resolution. Name resolution \textit{``means that a resolution service is queried, and one or more lower-layer locators are returned. These locators can then be used to retrieve the object, using a protocol like HTTP or direct IP.''} Name resolution can be hybrid with name-based rooting \citep{OEHLMANN}. \bigskip

\noindent The general idea of routing of different ICN approaches is same. However, how routing can be actually deployed in different approaches vary a lot.

\subsection{Caching}


\marginpar{\scriptsize Figure \ref{fig:7}: The user starts with requesting a content movie.flv and issues an interest message. ICN Node has the content movie.flv in its cache and issues a data message.}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.6]{./Pictures/Figure7.png}
\end{center}
\caption{ICN caching 1}
\label{fig:7}
\end{figure}
\marginpar{\scriptsize Figure \ref{fig:8}: If ICN Node does not have the content in its cache then the Node transfer the interest to the rest of the network, once the content is found a Data message is delivered along the path. ICN Node makes a space for the Data by removing some content. ICN Node forwards the content to the user and store a copy in the cache.}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.6]{./Pictures/Figure8.png}
\end{center}
\caption{ICN caching 2}
\label{fig:8}
\end{figure}

\noindent One of the features of ICN is In-Network Caching where the data can be cache through the delivery path or within the network. \textit{``In ICNs, the caching decision process is based solely on local information. Nodes take into account content requests and data delivered when determining which content to keep. In essence, any node of the network, including user systems, can act as a cache at any time, enabling existing networks to be extended into private and public content distribution networks, even on global scale''} \citep[p. 22]{BRITO}. \bigskip

\noindent The design is for a client or a user to save time for going all the way to the hosting server when requesting a data or content, thus aim is to put the content closer to the user. Packet address indicates the content rather than the location. User request a specific content by issuing an Interest message and a node having that specific content will answer with Data message. The figures \ref{fig:7} and \ref{fig:8} illustrate how caching is done in Information Centric Network (ICN).

\subsection{ICN Proposed Architectures}
There are several proposals for ICN have been developed. Many of these proposals are focused on clean-slate communication architecture to replace the current model based on TCP/IP. All these projects have applied the basic content-centric concepts of ICN but with different architectures. \bigskip

\noindent In this section we describe briefly some of the main ICN architecture proposals that are funded in Europe. We explain CCN (USA/PARC funded) architecture with more details in a separate section below.

\subsubsection{Publish/Subscribe Internet Routing Paradigm (PSIRP)}

PSIRP \citep{TARKOMA} project is a EU FP7 clean-slate architecture project for the future Internet. It envisions removing the current Internet limitations by designing a new core network mechanisms instead of continuous adding fixes. \bigskip

\noindent PSIRP architecture is based on publish-subscribe paradigm, which is completely different from the current one. It is composed of three basic elements: Publishers, subscribers and network of brokers. Publishers send publication messages through a network of brokers advertising the available information. Consumers in the other hand, that are interest for specific information, send subscribe messages to get them. Network of brokers is responsible for routing these messages between publishers and subscribers. Network of broker where the messages are exchanged between the senders and receivers is called Rendezvous Point (RP). RP allows messages to be distributed with multihoming, mobility, and anonymity regardless of location and time.

The PSIRP prototype has been implemented and testbed across Europe is already being established for testing proposes \citep{FOTIOU}.

\subsubsection{Publish/Subscribe Internet Technology (PURSUIT)}

PURSUIT is also a EU FP7 development (follow-on) project for the concepts that are implemented in PSIRP and make PSIRP architecture and protocol suite more complete to enhance scalability with more performance and investigations \citep{FOTIOU}.\bigskip

\noindent One of main PURSUIT goals is to develop solutions and mechanisms that should be able to make this new information-centric environment conflict free to enable providers to use and take advantage of it. It also aims to make resource utilization more efficient by providing multicast, caching and mobility as an in-network mechanism. Enhancing security and privacy by developing a framework that will enable flexible definition of policies at all levels of the architecture is another goal of PURSUIT project \citep{FOTIOU}.\bigskip

\noindent \textit{``Moreover, the PURSUIT team will seek collaborations with other projects developing similar architectures and technologies in order to join forces towards a realistic evaluation framework.''} \citep[p. 5]{FOTIOU}

\subsubsection{Data-Oriented Network Architecture (DONA)}
DONA is the first clean-slate information-centric architecture. It involves redesign of Internet naming and name resolution, where flat and self-certifying names handle persistence and authenticity, while name resolution (routing) handles availability. DONA's name and anycast name resolution mechanism replaces DNS names and DNS name resolution respectively \citep{BRITO}. \textit{``DONA names are organized around principals [or publishers]. Each principal is associated with a public-private key pair, and each datum or service or any other named entity (host, domain, etc.) is associated with a principal''} \citep[p. 3]{KOPONEN}. This association is critical to DONA naming.\bigskip

\noindent FIND(P:L) is the packet used in DONA architecture, where P is the principal's public key and L is an arbitrary label. DONA \textit{``does not entirely discard IP technology. The FIND packet is characterized by its insertion between the IP and transport layer headers, limited to content address resolution. Thus, conventional transport mechanisms are triggered to perform content delivery, only guiding those name-based mechanisms without major changes in protocols and the infrastructure that supports them.''} \citep[pp. 26-27]{BRITO} \bigskip

\noindent The anycast name routing process itself implies insurance of the data authentication, and this mechanism provides clean support for network imposed Middleboxes that are used in the current Internet to improve security \cite[p. 2]{KOPONEN}. \bigskip

\noindent Anycast name routing enables also the use of path-labels rather than global IP addresses, which improves the scalability of routing. Content requests are guided to the best serving nodes to avoid overload and faulty in DONAs routing mechanism, and only the allowed Nodes can provide access to content in DONA paradigm. Users should search for content names through different providers \cite[p. 2]{KOPONEN}.

\subsubsection{Translating Relaying Internet Architecture integrating Active Directories (TRIAD)}

TRIAD was the first work to propose using the existing techniques URLs in HTTP request for delivering content. The key aspect of TRIAD is that TRIAD uses a content layer for content routing, caching and content transformation. The end-to-end identification in TRIAD is based on names and URLs. TRIAD uses a protocol WRAP on the top of IPv4 for content routing control and extensible addressing. With extensible addressing in TRIAD, there is less need for IPv6 to be deployed in the future. TRIAD is compatible with IPv4, TCP, DNS and other Internet protocols. Therefore, TRIAD can be easily deployed without changes to end-users or applications expect those already be deployed \citep{HERITON}.

\subsubsection{Network of Information (NetInf)}
NetInf is an architecture proposed by the 4WARD\footnote{\url{www.4ward-project.eu}} project. NetInf is not an application-layer overlay. It is a unique position to use \textit{``other technologies ranging from virtualization to network coding to in-network management.''} \citep[p. 1]{VAN} \bigskip

\noindent This architecture also includes some concepts of DONA and PSIRP/PUR{\-}SUIT. These concepts are flat names and DHT-based routing \citep[p. 40]{BRITO}. The key aspect of NetInf is that NetInf retrieves Data Objects based on unique identifiers, including two steps: \textit{``First, 'name resolution' locates an object in the network. Then, 'routing' forwards (a) the object retrieval query to its storage location(s) and (b) the Data Object from its storage location(s) to the requesting client.''} \citep[p. 3]{VAN}

\subsubsection{Multi-cache}
Multi-cache architecture aims to use the network resources efficiently. It is based on two primitives, which are multicast and caching. Multi-cache uses overlay multicast to deliver content and uses multicast forwarding information to locate nearby caches. In Multi-cache architecture, network operators deploy and control proxy overlay routers to enable the \textit{``joint provision of multicast and caching.''} \citep[p. 1]{ATSAROS} End-hosts just need to provide location identifiers. Scribe overlay multicast scheme\footnote{Scribe is a scalable application-level multicast infrastructure. Scribe supports large numbers of groups, with a potentially large number of members per group. Scribe is on top of Pastry} is used to transport the content from its origin inside the network, so synchronous requests could be served. With the locality awareness of Pastry routing substrate\footnote{Pastry is a scalable distributed object location and routing substrate for wide-area peer-to-peer application.}, anycast queries can be used to locate nearby caches, which can serve asynchronous requests via unicast. \citep[p. 1]{ATSAROS} \bigskip

\subsection{Content-Centric Networking / Named-Data Networking}
\bigskip
Van Jacobson at PARC invents CCN. CCN is the most known network architecture in USA that is made to solve challenges in content distribution, security and Internet congestion. It uses an addressing scheme based on names only, not location, and it divides Content into chunks with unique hierarchical names that can be interested separately \citep{VAN}. \bigskip

\noindent CCN Routing is strongly derived from the IP. It routes the user request to the closest Node that has a copy of the content, to deliver it to the user. It also caches a copy of the content locally in the Node to be able to satisfy next requester of the same content quickly and efficiently. It is always checked for security information that is embedded in the content, which make it more robust \citep{VAN}.\bigskip
\bigskip

\noindent There are two messages used in CCN Architecture: Interest (request) message and Content Object (response) message. \citep[p. 2]{VAN} \bigskip

\noindent NDN project is US project, and it uses CCN architecture to adopt full ICN concepts. It has a test-net\footnote{\url{http://named-data.net/ndn-testbed/}} in USA with more than 11 Nodes. \bigskip
\bigskip
\bigskip
\subsubsection{CCN Consumer-Node Communication Processing}
The CCN Node has 4 major components: Face, Content Store (CS), Pending Interest Table (PIT), and Forwarding Information Base (FIB). More details about these components are written in the following sub-sections.
\bigskip

\begin{figure}[H]
\begin{center}
\includegraphics[scale=0.13]{./Pictures/Figure9.jpeg}
\end{center}
\caption{An overview of Interest \& Content Object messages processing inside a CCN Node.}
\label{fig:9}
\end{figure}
\noindent Figure \ref{fig:9} depicts the overall communication process between Internet consumer and CCN Node. CCN Node through one of its faces will receive the Interest message that a user sends for requesting a Content Object. The Interest message's ContentName will be checked, and if is found in CS then CS discards the message and sends Content Object message back to the user contained the data he or she requested. CS may have multiple Content Objects that match Interest message; therefore CS should use the other specification in the Interest message to determine which exact Content Object to return.

If ContentName does not match with CS, the Interest message is sent to PIT contains a list of all Interest messages that have been requested by all users before. PIT will check this list if same message has been through and is being pending. If a matching Interest message is found the arrival face and the user address is saved in a list for unsatisfied Interests and the Interest message is discarded. But if Interest message does not exist, it will be added to that list, and it will then be sent further to FIB.

FIB in turn will look for the Content Object somewhere else in the Internet or from the producer to get a copy of it home. FIB will at the same time ask PIT to create an entry identifying the arrival face for that Interest message to know where to forward the Content Object when it a arrives. When any Node has the Content Object, it will forward a copy of it to the asking Node. The Node will then forward it to the Interest user via a Content Object message and keep a copy of it in Content Store component. If the requested content is not found in the CS, PIT and FIB, it means that the Content Object does not exist and there is no way to find it. The Interest message will therefore be discarded \citep{VAN}.

\subsection{CCN Architecture}
In this section we have chosen CCN architecture to give a detailed understanding of how the content data is proceeding in an ICN environment. \bigskip

\noindent The Content-Centric Networking architecture is concern about the content that is based on named data which user requests. It delivers Content Object to the user rather than connecting hosts to other hosts. The Content Object can be cashed at any CCN router, and it supports multicast delivery, which makes communication much faster, and especially efficient when many users are interested in the same Content Object \citep[p. 1]{VAN}. \bigskip

\noindent CCN uses two types of messages; one for requesting Content Object called Interest message and one for responding with the data called Content Object. Exchanging of these two messages goes through the CCN Node. If the Node has the Content Object cashed locally, it will forward a copy of it to the requester; else it will look after it in other near Nods if they have cashed it before or from the producer himself using the CCN Routing process. Each time content is forwarded to the requester; the Node keeps a copy of it locally. This is called CCN Cashing \citep[p. 2]{VAN}.

\subsubsection{The big picture}

\begin{figure}[H]
\begin{center}
\includegraphics[scale=0.4]{./Pictures/Figure10.jpg}
\end{center}
\caption{An overview of the main Content-Oriented Networking features: content routing, caching, and content signature. Content is address by name (x). \citep[p. 2]{CHAABANE}}
\label{fig:10}
\end{figure}

\begin{figure}[H]
\begin{center}
\includegraphics[scale=0.25]{./Pictures/Figure11.jpg}
\end{center}
\caption{Traffic overview when data is moved near to the user}
\label{fig:11}
\end{figure}

\noindent In the Figure \ref{fig:10} a consumer sends an Interest message to the Internet asking for content by its name. The nearest Node to this consumer on Internet receives this message and responses with Content Object message. If the Neighbour Router does not have this Content Object, it will ask a so-called Content Router for forwarding the requested Content Object. When any of them has not that needed Content Object, the Producer is being asked. The Content Object that satisfies will be forwarded to the requester and a copy of it will be kept (buffered/cashed) locally to serve other Interest messages for the same Content Object in the future. It will be deleted after a sort of time, if it is not requested \citep[p. 2]{CHAABANE}.

The Figure \ref{fig:11} illustrates many users want to watch the same YouTube video. Having this video in a Node near to the user will make it much reliable for both provider and user without needing to route the same video through many routers for every request.

\subsubsection{CCNx}
CCNx protocol is designed to be part of the application processing making communication between network applications end-to-end. It supports content applications as well as real-time communication, and it distributes data by its explicit and unique name in the network independently of its identity or location.\footnote{\url{http://www.ccnx.org/releases/latest/doc/technical/CCNxProtocol.html}} )\bigskip

\noindent XML schemas are used to define CCNx protocol data formats, and they do not have any fixed length fields. The protocol depends on hierarchical structure of the names that are consisting of a number of components with explicitly specified and identified divisions.\footnote{\url{http://www.ccnx.org/releases/latest/doc/technical/CCNxProtocol.html: p. 2}} \bigskip

\noindent CCNx content names and their component parts are formatted by applications, institutions, and/or global conventions, and are referred to as prefix.\footnote{\url{http://www.ccnx.org/releases/latest/doc/technical/CCNxProtocol.html: p. 4}}  \bigskip

\subsubsection{CCN Messages}
As mentioned before, there are only two types of messages used in the CCN communication, namely: Interest message that consumer sends to the Internet (like HTTP Request) and Content Object message that CCN Node delivers to the requester (like HTTP Response). Theses two packets are demonstrated in the Figure below.

\subsubsection{Interest message}


\noindent CCN can be layered over anything, including IP itself. It secures the Content Object by itself rather than through IP Physical Layer making it more robust and independent of the physical media that the data travels through \citep{VAN}.

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.17]{./Pictures/Figure12.jpg}
\end{center}
\caption{Interest Packet \citep[p. 45]{OEHLMANN}}
\label{fig:12}
\end{figure}

\noindent When a CCN user wants some data, he or she can request it by its exact name using the Interest message Figure \ref{fig:12}. The data can also be requested by defining other qualifications to restrict what data is acceptable.

CCN senders are stateless, therefore the application that initiates the Interest message is responsible to retransmit it again if Content Object message is not received after a sort of time, if it still wants it. This means that the receiver controls the data-communication within CCNx protocol \citep[p. 45]{OEHLMANN}.

\subsubsection{Content Object message}
\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.17]{./Pictures/Figure13.jpg}
\end{center}
\caption{Content Object Packet \citep[p. 45]{OEHLMANN}}
\label{fig:13}
\end{figure}

\noindent The Content Object message Figure \ref{fig:13} is the response message that the user gets from the Node with a matched ContentName and Content Object in its 'Data' field. And because all CCN data must be attested, the Content Object message contains also an encrypted valid signature and the publisher identification. The requester application must verify the data received first by using required public keys, and it must discard the Content Object message if it fails to verify. \citep[p. 45]{OEHLMANN}\bigskip

\noindent \textit{``The CCNx protocol is designed to ensure attestation of data, without constraining decisions about key distribution and trust management.''}\footnote{\url{http://www.ccnx.org/documentation/ccnx-protocol-2/}} \bigskip
Content Object message must only send to the receiver if it is requested by an Interest message and only if it has the data that matches.  \citep[p. 45]{OEHLMANN}


\subsubsection{CCN Node}

The Node is an entity within CCN architecture that has to do with forwarding and buffering of the Content Object.

\subsubsection{Node Data Structure}

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.3]{./Pictures/Figure14.jpg}
\end{center}
\caption{CCN forwarding engine model \citep[p. 2]{VAN}}
\label{fig:14}
\end{figure}

\noindent CCNx Node identity contains 4 major components Figure \ref{fig:14} Face, Content Store (CS), Pending Interest Table (PIT), and Forwarding Information Base (FIB) to provide buffering/caching and forwarding \citep[p. 2]{VAN}. \bigskip

\noindent The basic operation of a CCN Node is to receive the Interest message when it arrives on a face (interface), check its name, and perform an action based on the result from that check.

\subsubsection{Face}
A face is the Node interface to a network, application party or to a single application process on the same machine. It is used to send and receive data packets. \textit{``All messages arrive through a face and are sent out through a face''}\footnote{\url{ http://www.ccnx.org/documentation/ccnx-protocol-2}}

\subsubsection{Content Store (CS)}
Content Store is a buffer memory that keeps a copy of the Content Object for further severing any Interest message. The buffer in IP router does not keep the data after it has been served to the requester, which is the only difference compared to the buffer in CS. \bigskip

\noindent The CS should implement Least Recently Used (LRU) or Least Frequently Used (LFU) that are used for maintaining or deletion of Content Objects. CS must also implement one bit 'Staleness Bit' that is used for versioning or duplicating of Content Objects when they arrive on the face.
Any Node within a multiple networks can provide cashing and serve as a Content Router.

\subsubsection{Pending Interest Table (PIT))}
Pending Interest Table is a table of sources that keeps track of every new created entry from the Interest and its arrival face. This is important to know where the Interest message is from to be able to deliver the requested Content Object when arrived. There must be a fixed timeout for each entry.

\subsubsection{Forwarding Information Base (FIB)}
Forwarding Information Base has a prefix entry list with all the faces it knows. It works with multiple sources (faces) at the same time in parallel, which is the only difference compared to IP FIB.
FIB tries first to find the needed Content Object in the local environments such as manager's computer, colleague's laptop or phone. If the Content Object that satisfies the Interest is found then it will be forwarded to the Interest, else FIB will ask other Nodes in the Internet or the original producer to get a copy of matching Content Object.

\subsubsection{Flow balance}
\textit{``An Interest message MAY be transmitted using broadcast or multicast facilities of the underlying transport in order to reach many potential sources of data with minimal bandwidth cost. A party MUST transmit at most one Content Object message in response to a single received Interest message, even if the party has many Content Objects that match. This one-for-one mapping between Interest and Data messages maintains a flow balance that allows the receiver to control the rate at which data is transmitted from a sender, and avoids consuming bandwidth to send data anywhere it is not wanted.''}\footnote{\url{ http://www.ccnx.org/documentation/ccnx-protocol-2}}

\subsubsection{Suppression}
Each Node should implement suppression mechanisms to make sure that only one Content Object message is transmitted to a single Interest message. These suppression mechanisms should also make sure that any other responses to that specific Interest message from another node are discarded.

\subsection{Routing on content centric networking}
CCN provide a very good rooting scheme. CCN is compatible with IP. \textit{``Any routing scheme that works well for IP should also work well for CCN, because CCN's forwarding model is a strict superset of the IP model with fewer restrictions (no restriction on multi-source, multi-destination to avoid looping) and the same semantics relevant to routing (hierarchical name aggregation with longest-match lookup)''} \citep[p. 5]{VAN}. \bigskip

\noindent CCN can be easily applied to current Internet. Once a few ISPs start to implement CCN, then \textit{``it is in the ISP's best interest to deploy content router(s) to reduce peering costs while lowering customers' average latency''} \citep[p. 5]{VAN}.

Figure \ref{fig:15} illustrates how CCN implement the routing with using unmodified Internet link-state IGPs (IS-IS or OSPF) \citep[p. 5]{VAN}.

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.8]{./Pictures/Figure15.png}
\end{center}
\caption{Routing Interests \citep[p. 5]{VAN}}
\label{fig:15}
\end{figure}

\noindent This is an IGP domain with a combination of IP only routers that are single circle and IP+CCN routers that are double circles. A repository near A, which is an IP+CCN router, announces that it can serve an 'Interest' that matches the prefix '/parc.com/media/art'. A routing application on A receives this announcement and then installs a local CCN FIB entry for the prefix pointing at the This is an IGP domain with a combination of IP only routers that are single circle and IP+CCN routers that are double circles. A repository near A, which is an IP+CCN router, announces that it can serve an 'Interest' that matches the prefix '/parc.com/media/art'. A routing application on A receives this announcement and then installs a local CCN FIB entry for the prefix pointing at the face where it heard the announcement, then packages the prefix into IGP LSA, which is flooded to all nodes. IGP LSA's that are used as a transport for normal CCN messages, which have full CCN content authentication, protection, and policy annotation. When a different repository near to B announces '/parc.com/media' and '/parc.com/media/art', B floods an IGP LSA for these two prefixes with the result that E's CCN FIB is as shown in the figure. An interest in '/parc.com/media/art/impressionisthistory.mp4' expressed by a client near E will be forwarded to both A and B, who each forward it to their adjacent repository \citep[p. 5]{VAN}. \bigskip

\noindent CCN dynamically find the best way to optimize both bandwidth and delay. This delivery topology shown in the figure is clearly not optimal since D and C are only IP routers. That means if a client adjacent to F requested the same Interest, it would result that A and/or B will deliver the same content again to F then to the client. However, once C gets CNN software upgrade, the interests will be forwarded to the client directly from E and F \citep[p. 6]{VAN}. 

\subsection{Comparison of some different approaches}
We summerise some of the above mentioned approaches in the table below to give an overview of the differences of different characteristics of the ICN architecture, like deployment, naming, routing, and caching. On the time we made the comparison, these approaches here are still under development.

\begin{table}[h]
\begin{center}
\includegraphics[scale=0.5]{./Pictures/Figure16.png}
\end{center}
\caption{Comparison between different approaches \citep[p. 41]{BRITO} \citep[p. 1]{VAN} \citep{OEHLMANN}}
\label{fig:16}
\end{table}

\noindent CCN/NDN is an evolutionary approach. They are based on hierarchical naming to allow names to be aggregated. By using in-network caching, content is brought closer to the end users. CCN/NDN routing is very similar to current Internet routing. CCN/NDN use some of the concepts from TCP/IP, and extent them to provide a flexible network layer. \bigskip

\noindent With cryptographic hash function being used in flat naming scheme, the DONA names cannot be user-friendly and human readable, but this gives uniqueness and persistence to identifiers. \bigskip

\noindent PURSUIT/PSIRP is also one of the clean-slate approaches. Flat name scheme is applied to PURSUIT/PSIRP with uniqueness and persistence to identifiers, but they are not human-readable. The routing in PURSUIT/PSIRP \textit{``enables load distribution among all participating domains, normalizing the computational requirements of the network nodes.''} \citep[p. 42]{BRITO} \bigskip

\noindent NetInf is an evolutionary architecture too. It includes some concepts from DONA and PRUSUIT/PSIRP. NetInf do not offer human-readable names as they are using flat naming scheme. \textit{``NetInf has topologically embedded, nested, and hierarchically organized DHTs for Intra-AS routing and global name registration system called REX for Inter-AS routing''} \citep[p. 51]{FAIZUL}. This means that NetInf uses both name resolution and name-base routing to retrieve content.
